Common gateway to call control systems

ABSTRACT

A method of and apparatus for supporting intelligent call routing (ICR) systems multiple vendors, in a vendor neutral fashion using a computer is described. One embodiment has a voice program send a call routing request using an HTTP format to a call routing program. The call routing program decodes the HTTP request and identifies the appropriate vendor-specific communication format and communications method for talking to the ICR system specified in the HTTP request. The call routing program sends the request and receives the answers from the ICR system in the vendor specific formats. The call routing program provides the ICR system response back to the voice program in a vendor neutral fashion. This approach allows voice programs to easily be written that work with multiple ICR systems and allow component reuse of call routing code amongst programs that end up working with multiple systems.

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to the field of phone based communications. Inparticular, the invention relates to methods for providing a uniforminterface to call center integration equipment that is vendor neutral.

2. Description of the Related Art

A variety of vendor specific call center integration equipment ismanufactured. More specifically call routing equipment is used tocontrol, and monitor, allocation of calls amongst a variety of callcenter facilities and provide support for database lookups and the like.The equipment is designed for programming using vendor specificprogramming interfaces and/or communication protocols. Accordingly onewould use a different approach to obtain information from a Cisco callrouting equipment than a Genesys call routing equipment.

This approach is limiting in the context of a phone application platformwhere calls for many vendors are being handled by a single platform. Itadditionally makes it difficult to describe programs in a vendor-neutralfashion.

Accordingly, what is needed is a method and apparatus for handling callcenter integration equipment in a vendor neutral fashion.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1A illustrates the components of a phone application platformsupporting the vendor neutral call center integration.

FIG. 1B illustrates the use of the system of FIG. 1A in call centerintegration.

SUMMARY OF THE INVENTION

A method of and apparatus for supporting intelligent call routing (ICR)systems multiple vendors, in a vendor neutral fashion using a computeris described. One embodiment has a voice program send a call routingrequest using an HTTP format to a call routing program. The call routingprogram decodes the HTTP request and identifies the appropriatevendor-specific communication format and communications method fortalking to the ICR system specified in the HTTP request. The callrouting program sends the request and receives the answers from the ICRsystem in the vendor specific formats. The call routing program providesthe ICR system response back to the voice program in a vendor neutralfashion. This approach allows voice programs to easily be written thatwork with multiple ICR systems and allow component reuse of call routingcode amongst programs that end up working with multiple systems.

DETAILED DESCRIPTION

A. Introduction

A method and apparatus for interfacing with call center routingequipment in a vendor neutral fashion is described. This approach can beused for a number of straightforward purposes from straightforward callrouting to allowing interactive hold.

The invention will be described in greater detail as follows. First, anumber of definitions useful to understanding the invention arepresented. Then, the basic architecture for a phone application platformsupporting the method is presented. Finally, the processes and featuresare presented in greater detail.

B. Definitions

1. Telephone Identifying Information

For the purposes of this application, the term telephone identifyinginformation will be used to refer to ANI (automatic numberingidentification) information, CID (caller identification) information,and/or some other technique for automatically identifying the source ofa call and/or other call setup information. For example, telephoneidentifying information may include a dialed number identificationservice (DNIS). Similarly, CID information may include text dataincluding the subscriber's name and/or address, e.g. “Jane Doe”. Otherexamples of telephone identifying information might include the type ofcalling phone, e.g. wireless, pay phone, and/or hospital phone.Additionally, the telephone identifying information may include wirelesscarrier specific identifying information, e.g. location of wirelessphone now, etc. Also, signaling system seven (SS7) information may beincluded in the telephone identifying information.

2. User Profile

A user profile is a collection of information about a particular user.The user profile typically includes collections of different informationof relevance to the user, e.g., account number, name, contactinformation, user-id, default preferences, and the like. Notably, theuser profile contains a combination of explicitly made selections andimplicitly made selections.

Explicitly made selections in the user profile stem from requests by theuser to the system. For example, the user might add business news to themain topic list. Typically, explicit selections come in the form of avoice, or touch-tone command, to save a particular location, e.g.“Remember this”, “Bookmark it”, “shortcut this”, pound (#) keytouch-tone, etc., or through adjustments to the user profile madethrough the web interface using a computer.

Additionally, the user profile provides a useful mechanism forassociating telephone identifying information with a single user, orentity. For example, Jane Doe may have a home phone, a work phone, acell phone, and/or some other telephones. Suitable telephone identifyinginformation for each of those phones can be associated in a singleprofile for Jane. This allows the system to provide uniformity ofcustomization to a single user, irrespective of where they are callingfrom.

In contrast, implicit selections come about through the conduct andbehavior of the user. For example, if the user repeatedly asks for theweather in Palo Alto, Calif., the system may automatically provide thePalo Alto weather report without further prompting. In otherembodiments, the user may be prompted to confirm the system's implicitchoice, e.g. the system might prompt the user “Would you like me toinclude Palo Alto in the standard weather report from now on?”

Additionally, the system may allow the user to customize the system tomeet her/his needs better. For example, the user may be allowed tocontrol the verbosity of prompts, the dialect used, and/or othersettings for the system. These customizations can be made eitherexplicitly or implicitly. For example if the user is providing commandsbefore most prompts are finished, the system could recognize that a lessverbose set of prompts is needed and implicitly set the user's promptingpreference to briefer prompts.

3. Topics and Content

A topic is any collection of similar content. Topics may be arrangedhierarchically as well. For example, a topic might be business news,while subtopics might include stock quotes, market report, and analystreports. Within a topic different types of content are available. Forexample, in the stock quotes subtopic, the content might include stockquotes. The distinction between topics and the content within the topicsis primarily one of degree in that each topic, or subtopic, will usuallycontain several pieces of content.

4. Demographic and Psychographic Profiles

Both demographic profiles and psychographic profiles contain informationrelating to a user. Demographic profiles typically include factualinformation, e.g. age, gender, marital status, income, etc.Psychographic profiles typically include information about behaviors,e.g. fun loving, analytical, compassionate, fast reader, slow reader,etc. As used in this application, the term demographic profile will beused to refer to both demographic and psychographic profiles.

5. Cookie

The term cookie, as used herein, refers to a structured data elementformatted according to the general principles of IETF RFC 2109 and/orsome other state management standard.

A brief review of RFC 2109 may be useful. The core structure of a cookieis a name-value pair. The name is a token for identifying the cookie,e.g. “Customer”, and the value is the value of that corresponding token,e.g. “Jane Doe”.

Implicitly, each cookie is associated with the sending domain. Accordingto RFC 2109, the implicitly set domain is the originating domain towhich the HTTP request was sent. For example, if an HTTP GET request issent to the request host “www.example.com”, then the cookie set inresponse to that request would be implicitly associated with“www.example.com”

Additionally, a number of optional fields can be set, for example: adifferent domain for which the cookie is valid (Domain); a time to live(Max-Age); a version string (Version); etc. The phrases in parenthesiscorrespond to the RFC 2109 standard field names for the options.

C. Architecture

First, the hardware and software architecture of a system including anembodiment of the invention will be described with reference to FIG. 2.FIG. 2 illustrates a system including embodiments of the invention usedto support phone applications, including the asynchronous communicationapplication. The system of FIG. 2 can be used to allow deployment ofphone applications without the need for specialized hardware and/orsoftware.

The following lists the elements of FIG. 2 and describes theirinterconnections. FIG. 2 includes the telephone 200A, a telephonenetwork 204, a telephone gateway 207, a phone application platform 210,a VoiceXML browsers and supporting servers 212, a network 222, anapplication provider platform 220, a brand X ICR gateway and equipment224, an agent station 230, a telephone 200B, and a computer 232. Thetelephone 200A is coupled in communication with the telephone network204. The telephone network 204 is coupled in communication with thetelephone gateway 207 and the application provider platform 220 (in someembodiments the telephone network 204 may be coupled to the agentstation 230 directly and/or a call center having multiple agentstations.) The telephone gateway 207 is coupled in communication withthe phone application platform 210. The network 222 is coupled incommunication with the phone application platform 210 and theapplication provider platform 220.

The following describes each of the elements of FIG. 2 in greaterdetail. The telephone 200A is a telephone interface to the phoneapplication platform 210. The telephone 200A may be any sort oftelephone and/or wireless telephone. For example the telephone 200A maybe a land line phone, a PBX telephone, a satellite phone, a wirelesstelephone, and/or any other type of communication device capable ofproviding voice communication and/or touch-tone signals over thetelephone network 204. However, any audio signal carrying interfacecould be used.

The telephone network 204 may be the public switched telephone network(PSTN) and/or some other type of telephone network. For example, someembodiments of the invention may allow users with a voice over InternetProtocol (IP) phone to access the phone application platform 210. Thetelephone network 204 is coupled to the telephone gateway 207 thatallows the voice communications and/or touch-tone signals from thetelephone network 204 to reach the phone application platform 210 inusable form. Similarly, the telephone gateway 207 allows audio signalsgenerated by the phone application platform 210 to be sent over thetelephone network 204 to respective telephones, e.g. the telephone 200A.The telephone network 204 generally represents an audio signal carryingnetwork.

The phone application platform 210 is comprised of one or more computersproviding the VoiceXML browsers and supporting servers 212. (In thisembodiment, VoiceXML is one of the implementation languages.) Theparticular configuration shown is designed to support outsourced, orhosted, telephony provisioning as seen by the separation of theapplication provider platform 220 from the phone application platform210. This allows the phone services to be provided by a different legalentity than the application and avoids the need of the legal entityproviding the call center to be aware of difficult telecommunicationsprovisioning issues associated with running the phone applicationplatform 210. A more detailed description of one possible embodiment ofthe phone application platform 210 and features for working with audiocontent see U.S. patent application Ser. No. 09/431,002, entitled“Streaming Content Over a Telephone Interface”, having inventors HadiPartovi, et. al., filed Nov. 01, 1999, and assigned to the assignee ofthe current application.

Having described the basic architecture and some details, we now turn toimplementation and other features in greater detail.

D. Implementation

A helpful starting point is to understand how ICR, or intelligent callrouting, works. Vendors such as Cisco (Geotel brand) and Genesys are thedominant providers of ICR hardware and systems in the United States. Ina traditional setting, the application provider has to develop an entirecall center system, including any phone applications, e.g. DTMF frontend menu, etc. The ICR systems are used to take the inputs to the DTMFsystems and control the routing of the calls to call agents. The moreadvanced ICR setups use database lookups (database not shown in elements222 or 224 of FIG. 1A) to identify customer records and perform callrouting.

Typical ICR decisions would be based on the database lookup,availability of agents at particular call center, and/or specialties ofthe agents and the correspondence of the same to the customer's needs. Aconcrete example may help, MegaBank has a single 800# where customerscan get banking services or insurance products. They call the 800# andpress “1” for banking and “2” for insurance. In that case, the ICRsystem would route the call to an appropriate banking or insurancerepresentative.

When these traditional prompting systems are built they have beendesigned to interoperate with the specific ICR systems used by anapplication provider. Thus, if MegaBank changes from Cisco to GenesysICR systems, their entire application would have to be re-coded to takeadvantage of the system.

Turning back to the present invention and the basic configuration ofFIG. 1A, the process for using an ICR gateway in a vendor independentfashion will be described with reference to the process flow arrows(dashed lines) of FIG. 1B.

The process starts with the phone call 300A from the telephone 200A. Inthis example, the telephone 200A is being used by a customer of theapplication provider platform 220. Over the phone call 300A, the user ofthe telephone 200A can interact with a voice application running on thephone application platform 210. In one embodiment the application isservers to the phone application platform 210 across the network 222,e.g. from a web server (not shown).

At some point in the application, the customer requests to speak to alive agent (either implicitly or explicitly). At that point, the runningVoiceXML application (VoiceXML is one of several possible applicationprogramming languages that may be available on the phone applicationplatform 210), issues a vendor neutral transfer request 310 to an ICRgateway 214. The format of the vendor neutral transfer request 310 willbe discussed in greater detail below.

Continuing the process, the ICR gateway 214 responds to the vendorneutral transfer request 310 by generating an appropriate vendorspecific request 320. The ICR gateway 214 needs to be programmed asingle time for each supported brand/variety of ICR equipment. In oneembodiment, one or more data are kept on the ICR gateway to specify theequipment vendor for a particular application provider. For example, asimple application URI to vendor table could be maintained along withthe address of the gateway, e.g.:

http://www.example.com/application1.vxml cisco- 192.168.168.10 prot-1http://www.example.com/application2.vxml geotel- 192.168.168.56 prot-4Other information such as encryption, specific dedicated (or virtual)network connections to use could also be specified. In otherembodiments, the vendor neutral request 310 specifies a specific ICR,e.g. the vendor X ICR 224, by a mutually agreed upon name, e.g.“MegaBankMainICR” for which suitable information is maintained in theICR gateway 214 (such as that shown above) to enable the generation ofthe vendor specific request 320.

The vendor X ICR gateway and equipment 224 then process the vendorspecific request 320 and returns a vendor specific response 340 to theICR gateway 214. The ICR gateway would then take the response 340 andprovide the VoiceXML browser VoiceXML code to effect the transfer 350.There are two predominant embodiments. In the first embodiment theVoiceXML code 350 is dynamically generated by the ICR gateway 214 (muchlike a CGI program might generate dynamic HTML for rendering in a webbrowser). In the other configuration, the VoiceXML code 350 comprisessending one or more predetermined VoiceXML events and setting one ormore VoiceXML variables.

In either event VoiceXML code (either the code 350 or the remaining codein the execution flow after the events are thrown back from the ICRgateway 214) are responsible for effecting the instructions indicated bythe vendor X ICR gateway 224. For this example, the response 340indicated to transfer the caller to the phone number +1 (800) 555-5555and include dialed digits “987654321”. In this example, the ICR, gateway214 threw events in the VoiceXML code 350 back to the then runningVoiceXML application indicating that a transfer was requested. If theapplication is correctly programmed, a transfer will result; shown asthe phone call 300B using “transfer-connect”, also known as “take backand transfer”. In some embodiments the call is tromboned with the phoneapplication platform 210 staying on the line to allow the interactivevoice application to resume after the tromboned leg of the phone callends.

The phone call 300B couples the phone 200A in communication with theapplication provider platform 220, or more specifically the call centerequipment at the application provider platform 220. The vendor X ICRgateway and equipment 224 is responsible for interacting with theapplication provider's equipment to route the phone call 300B to anagent, e.g. at the agent station 230, and provide any necessary screenpops 360 to the agent's computer 232. The screen pops allow an agent'sscreen to be pre-loaded with information about the customer, e.g. fromdatabase lookups, user dialed digits, the caller's telephone identifyinginformation, and more.

Vendor Neutral Request Format Details

The format of the vendor neutral request 310 and the VoiceXML code toeffect the transfer 350 will now be considered in greater detail. Thebasic request format is a URI transmitted using the HTTP protocolbetween the VoiceXML browser 212 that is executing the currentapplication and the ICR gateway 214. The following shows one possibleformat for the vendor neutral request:

-   -   http://<icr gateway>/<icr path>/?ICRName=<icr system        name>&ANI=<telephone identifying information>&DID=<user/app        supplied data>        Where <icr gateway> is a valid method of specifying the ICR        gateway 214 according to the URI syntax rules, <icr path> is the        appropriate path portion for the URI, where <icr system name> is        a defined name for specifying an ICR as known to the ICR gateway        214, where ANI is a portion of the telephone identifying        information associated with the telephone 200A and where DID is        user and/or application supplied data, e.g. dialed digits.

A specific example of placing a vendor neutral request from VoiceXMLcode may be helpful as shown by this short listing:

<subdialogsrc=“http://icrgateway.tellme.com/servlet/com.tellme.irc.TransferInfo?ICRName=MegaBank&amp;ANI={session.telephone.ani}&amp;DID-987654321”> <catch event=“icr.error”>  <audio>There was an ICRerror.</audio> </catch> . . . <catch event=“icr.normal”>  <audio>The ICRsays I should transfer you to  {session.icr.Label}</audio> </catch> . .. </subdialog>The ellipses (“. . . ”) indicate omitted code that might test for otherevents indicating result codes such as busy states, a default routingaction, and more. The specific event names can be modified for aparticular implementation as can the variable name(s) containing the ICRresponses.

A more typical result on catching a transfer request would look asfollows:

<catch event=“icr.normal”>  <transfer dest={session.icr.Label}/></catch>As the above example actually accomplishes a call transfer to therequested destination.

Depending on the capabilities of the particular ICR system there may beone or more types of requests, the above example was for “TransferInfo”,but other more request types are also possible depending on thecapabilities of ICR systems generally, e.g. “WaitTime”, which mightreturn the expected wait time for an agent, e.g. throwing the event“icr.waittime” with session.icr.waittime set to the wait time orthrowing “icr.unsupported” if the specific vendor's ICR doesn't supportthat query type.

A waiting time strategy is one example where the phone applicationplatform can interact extremely well with ICR type systems. That isbecause if the phone application platform 210 has access to applicationsproviding voice portal-style functions, e.g. access to news,information, entertainment, shopping, and other content, a user canaccomplish other tasks and be entertained while she waits for an agentto become available.

Depending on how the VoiceXML browsers 212 are implemented this maycreate some problems. Both the current VoiceXML 1.0 standard andproposals for VoiceXML 2.0 do not easily handle asynchronous events ofthe type described above One approach is to periodically send additionalqueries. This however requires that each VoiceXML application running onthe VoiceXML browsers 212 be modified to repeatedly request“WaitingTime” until it reaches a predetermined amount, e.g. 15-20seconds and then send a “TransferInfo” request.

A more logical approach would be to be able to specify a handler in theVoiceXML browsers 212 to periodically poll the “WaitingTime” andautomatically effect the transfer when ready. With this approach it maybe more logical to use a tromboned-type transfer so that if the userbecomes engaged in a useful activity (e.g. voice commerce) while holdingfor a live agent she can resume the other activity at the end of thetransfer.

E. Conclusion

In some embodiments, processes and apparatus of FIGS. 1A-1B can beimplemented using hardware based approaches, software based approaches,and/or a combination of the two. In some embodiments, the ICR gateway214 uses one or more computer programs that are included in one or morecomputer usable media such as CD-ROMs, floppy disks, or other media.

Some embodiments of the invention are included in an electromagneticwave form. The electromagnetic waveform comprises information such asthe ICR gateway 214. The electromagnetic waveform may include theprograms accessed over a network.

The foregoing description of various embodiments of the invention hasbeen presented for purposes of illustration and description. It is notintended to limit the invention to the precise forms disclosed. Manymodifications and equivalent arrangements will be apparent.

1. A method of supporting intelligent call routing (ICR) systems of atleast a first vendor in a vendor neutral fashion using a computersystem, the method comprising: receiving a request for a call routingfunction in a vendor neutral format from a program, the requestidentifying at least a first ICR system to receive the request;preparing the request in a vendor specific format for transmission tothe at least a first ICR system, the vendor specific format selectedaccording to the format used by the at least a first ICR system;transmitting the request in the vendor specific format to the at least afirst ICR system over a network; responsive to receiving a response overthe network from the at least a first ICR system, converting theresponse into a vendor neutral format; and relaying the response in thevendor neutral format to the program.
 2. The method of claim 1, whereinthe program is a Voice Extensible Markup Language (VoiceXML) program,the vendor neutral format comprises a hypertext transfer protocol (HTTP)request and wherein the first ICR system is identified by the HTTPrequest.
 3. The method of claim 1, wherein the vendor specific format isnot an HTTP request.
 4. The method of claim 1, wherein the networkcomprises a dedicated connection to the at least a first ICR system andthe transmitting further comprises establishing a communication channelacross the dedicated connection.
 5. The method of claim 1, wherein thenetwork comprises a virtual connection to the at least a first ICRsystem and the transmitting further comprises establishing acommunication channel across the virtual connection.
 6. The method ofclaim 1, further comprising maintaining data specifying the vendorspecific format and the network for handling requests to the first ICRsystem and providing one or more programs for communicating in thevendor specific format of the network.
 7. The method of claim 1, whereinthe program is a VoiceXML program and wherein the relaying comprisesgenerating one or more predetermined events and setting one or morevariables in the execution context of the VoiceXML program according tothe response.
 8. The method of claim 7, the one or more predeterminedevents comprises a transfer event and wherein the one or more variablesincludes a transfer number variable.
 9. An apparatus for supportingintelligent call routing (ICR) systems of at least a first vendor in avendor neutral fashion using a computer system, the apparatuscomprising: means for receiving a request for a call routing function ina vendor neutral format from a program, the request identifying at leasta first ICR system to receive the request; means for preparing therequest in a vendor specific format for transmission to the at least afirst ICR system, the vendor specific format selected according to theformat used by the at least a first ICR system; means for transmittingthe request in the vendor specific format to the at least a first ICRsystem over a network; means for converting the response into a vendorneutral format responsive to receiving a response over the network fromthe at least a first ICR system; and means for relaying the response inthe vendor neutral format to the program.
 10. An electromagneticwaveform comprising a computer program for supporting intelligent callrouting (ICR) systems of at least a first vendor in a vendor neutralfashion using a computer system, the computer program comprising: afirst set of instructions for receiving a request for a call mutingfunction in a vendor neutral format from a program, the requestidentifying at least a first ICR system to receive the request; a secondset of instructions for preparing the request in a vendor specificformat for transmission to the at least a first ICR system, the vendorspecific format selected according to the format used by the at least afirst ICR system; a third set of instructions for transmitting therequest in the vendor specific format to the at least a first ICR systemover a network; a fourth set of instructions for converting the responseinto a vendor neutral format responsive to receiving a response over thenetwork from the at least a first ICR system; and a fifth set ofinstructions for relaying the response in the vendor neutral format tothe program.
 11. The method of claim 10, wherein the third set ofinstructions further comprises a set of instructions for interfacingwith a vendor provided programming library.
 12. The method of claim 10,wherein the third set of instructions further comprises a set ofinstructions for interfacing with a vendor provided application.